Join us

Agile Methods for UX Design

Closes in
22
hrs
11
mins
35
secs
37% booked
Intermediate

How This Course Will Help Your Career

What You Will Learn

  • What agile is, why it was developed, and how it can vary in different companies.

  • Common team structures and why it’s easier to design within those environments.

  • Agile-related concepts, terminology and tools including sprints, backlogs, user stories, Scrum and Kanban.

  • Agile patterns, anti-patterns and variations of agile practices such as Sprint Zero and Dual Track Agile.

  • How to adjust your design and research processes to work more comfortably and effectively within many different agile environments.

  • Research and design techniques such as continuous discovery, designing the smallest possible thing and design slicing.

  • Techniques for better team collaboration and cooperation. 

  • Common agile deliverables and how they differ (and how they don’t differ) from typical design deliverables.

Agile, in one form or another, has taken over the software development world and is poised to move into almost every other industry. The problem is that a lot of teams and organizations that call themselves “agile” don’t seem to have much in common with each other. This can be extremely confusing to a new team member, especially if you’ve previously worked on an “agile” team that had an entirely different definition of “agility”!

Since the release of the Agile Manifesto in 2001, agile methodologies have become almost unrecognizable in many organizations, even as they have become wildly popular. 

To understand the real-world challenges and best practices to work under the constraints of agile teams, we spoke with hundreds of professionals with experience working in agile environments. This research led us to create Agile Methods for UX Design.

In this course, we aim to show you what true agility is and how closely agile methodologies can map to design. You will learn both the theory and the real-world implementation of agile, its different flavors, and how you can work with different versions of agile teams.

You will learn about the key principles of agile, examples of teams that perform all the agile “rituals” but aren’t actually agile, and examples of teams that skip the rituals but actually embody the spirit.

You’ll learn about agile-specific techniques for research and design, such as designing smaller things, practicing continuous discovery, refactoring designs, and iterating.

You will also walk away with practical advice for working better with your team and improving processes at your company so that you can get some of the benefits of real agility.

This course is aimed at people who already know how to design or research (or who want to work with designers and researchers) but who want to learn how to operate better within a specific environment. There are lots of tools designers use within an agile environment that are no different from tools they’d use anywhere else, and we won’t be covering how to use those tools generally, but we will talk about how agile deliverables can differ from those you’d find in a more traditional UX team. 

Your course instructor is product management and user experience design expert, Laura Klein. Laura is the author of Build Better Products and UX for Lean Startups and the co-host of the podcast What is Wrong with UX?

With over 20 years of experience in tech, Laura specializes in helping companies innovate responsibly and improve their product development process, and she especially enjoys working with lean startups and agile development teams.

In this course, you will also hear from industry experts Teresa Torres (Product Discovery Coach at Product Talk), Janna Bastow (CEO and Co-founder of ProdPad) and Adam Thomas (product management strategist and consultant).

Gain an Industry-Recognized UX Course Certificate

Use your industry-recognized Course Certificate on your resume, CV, LinkedIn profile or your website.

Course Certificate example

Our courses and Course Certificates are trusted by these industry leaders:

Our clients: IBM, HP, Adobe, GE, Accenture, Allianz, Phillips, Deezer, Capgemin, Mcafee, SAP, Telenor, Cigna, British Parliament, State of New York

Is This Course Right For You?

This is an intermediate-level course for people working in agile teams. Specifically, it will be helpful for:

  • Designers and researchers who have never worked in an agile environment or who have been frustrated by some aspects of working in one.

  • Non-designers who want to learn how to integrate UX into their agile process.

  • Business stakeholders and product owners who want to understand why designers might be frustrated or not performing well on a particular agile team.

In order to get the most out of this course, we recommend that you have some working experience on a team within a company, preferably as a designer, researcher, or engineer. You can still take the course if you don’t have this experience, but some of the material may be more challenging. 

Learn and work with a global team of designers

When you take part in this course, you will join a global multidisciplinary team working on the course and the exercises at the same time as you. You will work together to improve your skills and understanding. Your course group will be made up of an incredibly diverse group of professionals, all of whom have the same objective — to become successful designers. It’s your chance to learn, grow, and network with your peers across the planet.

Course Overview: What You'll Master

  • Each week, one lesson becomes available.
  • There's no time limit to finish a course. Lessons have no deadlines.
  • Estimated learning time: 19 hours 17 mins spread over 8 weeks .

Lesson 0: Welcome and Introduction

Available once you start the course. Estimated time to complete: 1 hour 1 min.

Lesson 1: What Is Agile and Where It Came From

Available once you start the course. Estimated time to complete: 2 hours 58 mins.

Lesson 2: Agile Patterns, Anti-Patterns and Myths

Available anytime after Apr 11, 2025. Estimated time to complete: 2 hours 42 mins.

Lesson 3: How Researchers Can Succeed on Agile Teams

Available anytime after Apr 18, 2025. Estimated time to complete: 3 hours 32 mins.

Lesson 4: How Designers Can Succeed on Agile Teams

Available anytime after Apr 25, 2025. Estimated time to complete: 2 hours 28 mins.

Lesson 5: How to Design for Experimentation

Available anytime after May 02, 2025. Estimated time to complete: 2 hours 14 mins.

Lesson 6: How to Build Products More Collaboratively

Available anytime after May 09, 2025. Estimated time to complete: 4 hours 22 mins.

Lesson 7: Course Certificate, Final Networking, and Course Wrap-up

Available anytime after May 16, 2025.

How Others Have Benefited

Andrea Sabaté

Andrea Sabaté, Spain

“The course was so complete and based on experience. I realised it because agile is very different comparing theory and practice. I would have liked to discover this course before entering the agile world. It is a superb course! So much wisdom shared!!”

Milad Kardgar

Milad Kardgar, Iceland

“Laura Klein is one of the best instructors I've ever seen. She is a UX designer with a demonstrated background in UX in practice and agile methodology indeed. Asking other professionals to share their knowledge was truly informative, in my opinion.”

Devina A. Paramita Na

Devina A. Paramita Na, Sweden

“Her way of explaining is really engaging. Adding a bit of humor here and there. It was really fun to follow. The examples are also great. I really enjoyed the course.”

See other reviews

How It Works

  1. Take online courses by industry experts

    Lessons are self-paced so you'll never be late for class or miss a deadline.

  2. Get a Course Certificate

    Your answers are graded by experts, not machines. Get an industry-recognized Course Certificate to prove your skills.

  3. Advance your career

    Use your new skills in your existing job or to get a new job in UX design. Get help from our community.

Start Advancing Your Career Now

Join us to take “Agile Methods for UX Design”. Take other courses at no additional cost. Make a concrete step forward in your career path today.

Advance my career now
Agile Methods for UX Design
Closes in
22
hrs
11
mins
35
secs
37% booked
Privacy Settings
By using this site, you accept our Cookie Policy and Terms of Use.

Agile Methods for UX Design

1.3 - Why Is Design Missing in Agile?

Show Hide video transcript
  1. 00:00:00 --> 00:00:34

    In order to really understand Agile,  it's important to know what Agile *isn't*. Agile didn't just appear from a vacuum; it was a  reaction to the way software was being written in the '80s and '90s. Back then, most of us did  something called Waterfall. I mean, Waterfall was really the best-case scenario because sometimes  there was absolutely no process at all. But when there *was* a process, it was often Waterfall. And even Waterfall had a lot of different versions, but we're going to look at the most optimistic  one that actually... included some design.

  2. 00:00:34 --> 00:01:03

    When you look at Waterfall, it makes some  sense. Somebody, probably a product manager, comes up with an idea for what  needs to be built and presents some requirements. These could take a lot of different  forms, but frequently they were in something called a product requirements document, or a PRD, or  sometimes a marketing requirements document (MRD). These were frequently *extremely long* documents  with a *lot of detail* about what a product should do. In the best-case scenario, that detail was drawn  from research and an understanding of the needs of 

  3. 00:01:03 --> 00:01:34

    both the user and the business ... and in reality, maybe not quite so much. Once the product managers were done, then we entered the design phase. Now, design was often its own little sort of mini Waterfall, but again, in the best cases, it was a good, solid user-centered design process – one that you're hopefully familiar with. It involved lots of user research to understand users in their context and lots of ideating and iterating and  prototype testing and all of that good stuff. In the worst cases, well, we drew a lot of pictures  of things that would never get built, to be honest.

  4. 00:01:34 --> 00:02:01

    The thing is that with these long cycles, the  requirements gathering and design process could last *a while* – almost always months, sometimes a  year; it depended on how big the product was. And a lot of times this was all before a single  line of code got written. That's because when you look at Waterfall, each little drop-off  is really what's called a *staged gate*. What that means is that after the process happened, the  requirements document or the design or whatever,

  5. 00:02:01 --> 00:02:32

    there would be a review process of the output  before it moved through the gate to the next step. Development couldn't happen before design ended, because the design had to be fully vetted before resources were committed to building. After all, you wouldn't want to spend a lot of money writing code if everything was just going to change, right? Again, this all sounds really reasonable – everybody agrees what we're building before we start building it. Who could be against this? Well, we're not done yet! Since requirements gathering was done *before* the design process, often things would show up in the design phase that invalidated  something from the requirements doc.

  6. 00:02:32 --> 00:03:02

    Maybe something changed in the six months that  product management took to write up 300 pages. Maybe we learned new information in  user research... who can say? Things change – which meant going back to redo the requirement ... and then back again once the requirements were fixed. Also, since design worked *independently* of  engineering most of the time, even after the design phase was "over", it was not  unusual for engineers to send the "finished" designs back with a nasty note saying, "This is a  pipe dream and will take us 400 years to build." or

  7. 00:03:02 --> 00:03:33

    something like that. That's always what it sounded  like to me, anyway. The same thing happened with quality assurance team at the testing step, except they would just file bugs for the engineers to fix. Anyway, what all of this means is that the  diagram often looked more like this. And it took a really, *really* long time. In a lot of cases, there wasn't any way to get around this process since at the end of the waterfall, we'd be printing a  bunch of CD-ROMs or even putting things directly into hardware, so there was really no going back and fixing stuff later like you can with internet-connected software.

  8. 00:03:33 --> 00:04:03

    The real problem, though, lay  in the *complete separation of the departments*. Engineering often didn't get much input into  the process until requirements were already set, despite the fact that requirements could be  drastically affected by engineering decisions and requirements sometimes changed, even from  the time that the 300-page document was written and approved to when the engineers  finished working on it. In other words, market forces could change or we could learn  things from the users or the engineers would find some really hard problem that couldn't be solved,  and then *everything* had to be changed

  9. 00:04:03 --> 00:04:31

    because it was incredibly hard to change one thing in that  300-page document without everything cascading ... because of *the waterfall* – get it? If something on page 28 changed, it meant that everything from page 29 to 300 *also* needed to change, and that was what we liked to call an enormous nightmare. Let's not even talk about feature creep, which happened  when people from step one realized that they'd forgotten a whole bunch of stuff and tried to  squeeze it in around step three or four, causing

  10. 00:04:31 --> 00:05:03

    the requirements to balloon out of control, and  all of the deadlines – which were ridiculous in the first place – would just get missed. Anyway, is there really any wonder why the engineers of the time might be interested in something a little bit more flexible – something where maybe every single decision didn't get made up front and then changed later; something where we *admit that we don't know everything*, so we're not going to bother trying to specify everything out to the last bit and byte, and we're going to build  some stuff and get *feedback and adjust as we go*. Throw in the fact that around this time websites  and web applications were really starting to take off;

  11. 00:05:03 --> 00:05:36

    and it was getting a lot easier to  get feedback directly from customers and make *continuous changes* rather than having  to chisel everything into stone before packaging it all up and sending it to the store  to sit on shelves – which is how people used to buy software; I mean, not the stone part, but the store part. Obviously, this wasn't everybody's experience of Waterfall. Between you and me, a lot of really good stuff has been built Waterfall-fashion – it's not a horrible system. In fact, most physical products and large civic projects like bridges and skyscrapers are built in a *mostly* Waterfall fashion.

  12. 00:05:36 --> 00:05:48

    But it's also not surprising that a lot of high-level engineers were not huge fans of it and they'd come up with something that was significantly less frustrating for them. And it's *really* not surprising that it would catch on.

Agile Methods for UX Design

3.3 - Innovation vs. Incremental Improvement

Show Hide video transcript
  1. Transcript loading…

Agile Methods for UX Design

3.5 - Collaborating with Your Team for Research

Show Hide video transcript
  1. Transcript loading…

New to UX Design? We're Giving You a Free eBook!

The Basics of User Experience Design

Download our free ebook “The Basics of User Experience Design” to learn about core concepts of UX design.

In 9 chapters, we'll cover: conducting user interviews, design thinking, interaction design, mobile UX design, usability, UX research, and many more!

A valid email address is required.
315,748 designers enjoy our newsletter—sure you don't want to receive it?

Course FAQ

loading content…